<syntaxPlanning>

Flexible enough to become an AGI
	100 YES

Using Audivolv (but not writing code) is easy enough for who to use?
	100 Anyone

Manually creating the things that Audivolv would normally evolve is easy enough for who to use?
	70 Average programmers.
	20 Average people that are not programmers.
	10 Geniuses.

Definition of aray sizes in a node can only depend on constant-depth recursion (ignoring if variable-depth recursion is allowed).
	90 YES
	10 NO

How many curIndex for which aray(s)?
	55 1 currentIndex for each group of arays the same size. There must be some way to know which int is for which group of arays. There are multiple currentIndex if the same aray is used multiple times in recursive loops or if multiple arays in that group are used in recursive loops. HeapQueue int arays (which have opposite pointer indexs) complicate this because there are 2 ways to choose which index is first: index of the highest flo, or index of the first flo.
	45 Exactly 1. Multiple arays that are locked at the same size have duplicate currentIndex which must be synchronized, but does not have problems with heapQueue int arays (which have opposite pointer indexs). This is duplicated again for each extra use of the aray(s).

Funcs can call other funcs with unlimited-depth recursion and have no way to know if they will ever finish.
	50 NO
	45 They can push those funcs on a stack and an external func may call them if the func has not used too many resources like time and memory.
	5 YES. Evolved code is turing-complete. It will probably go into an infinte loop.

Evolved code uses int arays in ways other than is hard-coded?
	NO 90
	YES 10

*^ (and maybe ^* also) inherits from ^ inherits from * which inherits from +?
	40 YES, in this way:
		*^ ... varSize*(b b b) --> ^(b c) --> varSize+(b b b) --> *(b c) --> +(b c) --> 2 --> 1 --> 0
	35, NO. An aray pow whose size is defined by ^[b c] should have a property equal to the c aray that changes depending on the current index of pow. Example: pow.loop.c.loop.b.flo+=[mul p]
	25 YES, but I dont know about the variable size * and + arays.

Each func, except for flofunc, is an object with a function that takes 1 parameter: a funcState.
	50 NO. Each func is an object with a function that takes parameters for what would have been in that funcState object.
	45 YES.
	5 Each func can take different parameters.

Can node recursion include the same node multiple times?
	80 YES.
	20 NO. This could allow temporary variables to be stored in each node.

Funcs that do loops on the arays of a node can optionally do 1 small part of the constant-depth-recursive loops at a time.
	70 NO. That would add too much complexity.
	30 YES. Finding bugs is easier because we can watch funcs do any integer amount of what they normally do, without needing a Java debugger.

Everything in Audivolv's string syntax is in the same heirarchy, starting at the word "audivolv". Example: audivolv.flo.araySize^[2 7]
	90 YES
	10 NO

When defining a node, should aray types be defined the same place as aray sizes?
	60 YES, in this way: flo bigAray = ^[falseTrue threeTimesChild]
	40 NO.

Allow some types of func to work on an aray instead of a node?
	60 NO Flofuncs are the simplest type of func and they must also execute on the flo arays in a node.
	40 YES At least allow flofuncs to execute on a flo aray that is copied from/to a node by some other func that executes on a node.

Int is defined as bit^32 in a set-theory way.
	60 NO.
	40 YES. It does not make things slower because ints will be used directly.



<notImportant>
	If b*c == b^c, are there any positive values of b and c where knowing both b*c and b^c is not enough to know both b and c?
	This can be solved fast by trying all small values of b, dividing b*c by that, and checking if b power something equals b^c.

	Should x[y[z]] be the same as x.y.z, and b[c d] be the same as b[c].d? I dont know if that can be consistent.
	+[*2+1.*2 *2+1.*2] must eval to 4
	Can +[*2+1.*2 *2+1.*2] be written as +[*2+1.*2].*2+1.*2? NO.
</notImportant>


<planToCreateTheFirstVersionOfAudivolv>

	Build simple things that will be compatible with complex things created later.

	Create a hard-coded way of looping over a ^ and * aray together (instead of combining multiple smaller operators). It must be compatible with *, ^, and other instances of its own looping type.
	The name of that operator will be simpleLoop*^

	Create flofuncs that operate on a flo aray. Later, other funcs can be created that take a node parameter and read/write some of its flos, but these first flofuncs will be simple and take only a flo aray. That aray size must be at least the quantity of flos the flofunc will use.

	The simplest type of if-statement is a flofunc of 3 flo parameters that returns the first or the second depending on if the first is positive or not.

	How should if-statements that can run more code be defined?
	A common way of using an if-statement is inside a loop.
	Should an if-statement take 1 flo parameter and 2 Func parameters, and return 1 of the Func depending on if the flo is positive or not?

	How should loop*^ be accessed to iterate over arrays sizes b*c and b^c?
	Should its parameters be the 2 int sizes b and c?
	Should its parameters be 2 arays with sizes b and c?
	In each iteration, should it create 2 int indexs in ranges of b*c and b^c?
	It must not access the arays size b*c and b^c because the loop may be much bigger than the arays, but it may be ok to access the arays b and c. Its probably best to do all looping as ints, and do variable-depth recursion as multiple loops where each loop has known size.
	loop*^[b c] has loop size c*(b^c) and for each of those indexs calculates an index in b*c and an index in b^c.
	Should loops have a different syntax than the syntax for defining aray sizes?
	loop*^[b c]{x y} //where x is b*c and y is b^c
	???

	How should loop*^ be accessed when it is combined with a *?
	loop[x] means a linear loop over x
	To not use aray x but do use x in other loops, use loopIgnore[x].
	//
	b = 2 //aray
	c = 3 //aray to use as data in loopRoot
	d = 4 //aray to use as data in loopRoot
	loopd = loop[d]
	//
	*bc = *[b c] //aray
	loop*bc = loop*[loopIgnore[b] loop[c]]
	//
	loop*d*bc = loop*[loopd loop*bc]
	//
	^d*bc = ^[d *bc] //aray to use as data in loopRoot
	loop^d*bc = loop[^d*bc]
	//
	loopRoot = loop*^[loop*d*bc loop^d*bc] //In each of *[*bc ^[d *bc]] iterations, data is in some of the arays but not others.
	//loopRoot = loop*^[loop*[loop[d] loop*[loopIgnore[b] loop[c]]] loop[^d*bc]] //3 linear loops to use as data
	//Its not obvious that loopRoot's 2 parameters are * and ^ of the same things.
	//
	//That is too complex. Instead, group arays that must be the same size as eachother, and call that arayGroup,
	//and during a call of loopRoot, there are 0 or more loops on each arayGroup. Every loop has at most 1 aray that is the same size as itself and provides access to that aray. The loop's parameters must equal a loop for the parameters of the aray size definition.
	//This all defines 1 call of loopRoot as a tree of loops.
	//Write the above example again in this simpler way:
	//
	b = 2
	c = 3
	d = 4
		loopd = loop[d]
	*bc = *[b c]
	*d*bc = *[d *bc] is a loop
	^d*bc = ^[d *bc]
		loop^d*bc = loop^[d *bc]
	*^[*d*bc ^d*bc] is a loop
		loopRoot = loop*^[loop*d*bc loop^d*bc]
	//
	//Try again, this time requiring that ^[x y] can only be defined after loop*[x y].
	//loop*^(b c) --> loop^(b c) --> ^(b c) --> loop*(b c) --> *(b c) --> ...???... --> +(b c) --> 2 --> 1 --> 0
	//
	//Simplified: *^(b c) --> ^(b c) --> *(b c) --> +(b c)
	//
	//Does that heirarchy prevent dynamic things like heapQueue lookup from child of child?
	//
	Replace c with *(x y):
	*^(b *(x y)) --> ^(b *(x y)) --> *(b *(x y)) --> +(b *(x y))
	Replace b with ^(x y):
	*^(^(x y) *(x y)) --> ^(^(x y) *(x y)) --> *(^(x y) *(x y)) --> +(^(x y) *(x y))
	Is this a problem?: *^(x y) == *(x ^(x y))
	*^(x ^(x y)) --> ^(x ^(x y)) --> *(x ^(x y))
	//
	//Optionally, find *(x ^(x y)) in code and convert it to *^(x y), but it doesnt hurt anything to not do that.
	//Similarly, find *(x *(x x)) and convert it to ^(x 3). Does that have inner/outer loop ordering problems?
	//Similarly, find *(^(x y) ^(x z)) and convert to ^(x +(y z)). Does that have inner/outer loop ordering problems?


	Again: How should loop*^ be accessed when it is combined with a *?
	b = 2 //2 = *2+1.*2
	c = 3 //3 = *2+1.*2+1
	d = 4 //4 = *2+1.*2.*2
	*bc = *[b c]
	*d*bc = *[d *bc]
	^d*bc = *d*bc.^
	loopRoot = ^d*bc.*^
	This looks simple and probably will work well.

	Should numbers be definable the same way, starting at 0, with 2 operators available for even numbers?: +1 and *2
	and 1 operator available for odd numbers?: *2
	Should odd numbers also have the +1 operator? That would allow multiple ways to create most numbers.
	0 = 0
	1 = 0.+1
	2 = 1.*2 = 1.+1
	3 = 2.+1
	4 = 2.*2 = 3.+1
	5 = 4.+1
	33 = 0.+1.*2.*2.*2.*2.*2.+1
	Should the operators be?: *2+1 and *2
	33 = 0.*2+1.*2.*2.*2.*2.*2+1 //33 is the binary number 0100001, same as replacing "*2+1" with "1" and "*2" with 0 and "." with "".
	All integers can be written in log quantity of *2+1 and/or *2 operators. The first 0 could be written as *2.

	b = *2+1.*2 //2
	c = *2+1.*2+1 //3
	d = *2+1.*2.*2 //4
	*bc = *[b c]
	*d*bc = *[d *bc]
	^d*bc = *d*bc.^
	loopRoot = ^d*bc.*^

	To use loopRoot, specify which arays will be used as data and which will be ignored. Must specify for all arays in the loopRoot tree of loops. Not all loops can be arays. Some are only loops. Some are arays and can be ignored.
	do[
		*d*bc.loop[flo=[*d*bc flo0]]
		loopRoot.loop[flo+=[*d*bc ^d*bc]]
		loopRoot.loop[do[ ...multiple commands... ]]
	]

	*2+1.*2.*2+1.do[ //5 times, do this:
		*d*bc.flo=[*d*bc flo0]
		loopRoot.flo+=[*d*bc ^d*bc]
		loopRoot.do[ ...multiple commands... ]
	]

	Should an aray of 5 flo be defined as 5 multiply flo?
	theFloAraySize5 = audivolv.*[audivolv.*2+1.*2.*2+1 audivolv.flo]

	What does flo power 2 or flo multiply flo mean? Is that a hashtable of flo key to flo value?
	Or would that be 2 multiply flo?
	Can a size 59 heapQueue parallel to an Ob aray be viewed as *[59 +[flo ob]]?

	Instead of: *bc = *[b c]
	Define a flo aray this way: *bc = *[*[b c] flo]
	But it may be a problem to multipl *bc by another flo aray: *d*bc = *[*[d flo] *[*[b c] flo]]
	If an expression has a data type in it (like flo), it can be used as data in a loop.
	If it has no data type, its just an int expression, and is a loop that does nothing.
	Data: *[d flo] and  *[*[b c] flo]]
	Loop: *[d *bc].flo+=[d *bc] //This doesnt make sense. It needs the flo in the loop definition.

	dFlo = flo
	dAray = *[d dFlo]
	bcFlo = flo
	bcAray = *[*[b c] bcFlo]

	*[dAray bcAray].flo+=[dFlo bcFlo]

	The same way as specific flo are named, node as ob can be named to recurse into nodes in an ob aray.
	tf = 2
	childNode = bayesNode
	childAray = *[7 childNode]
	weightSumFlo = flo
	weightSumAray = *[*[tf childAray] weightSumFlo]
	weightFlo = flo
	weightAray = *[weightSumAray.^ weightFlo]
	theLoop = weightAray.*^
	do[
		weightSumAray.flo=[weightSumFlo flo0]
		theLoop.flo+=[weightSumFlo weightFlo]
	]


	In a simple neural-net-like algorithm, how should the flos in a heapQueue for child nodes of child nodes be changed?
	theHeapQueue = +[
		hqForward = *[hqSize=59 int]
		hqReverse = *[hqSize int]
		hqFlo = *[hqSize flo]
		hqOb = *[hqSize ob]
	]
	It can be viewed as: *[hqSize +[flo ob]] where the max flo/ob can always be found, and linear iterating is also doable, and changing any flo changes the order of linear iteration.

	Should the operator that multiplies arays be the same operator that defines types of arays?
	Example: *[*[x y] z] is an aray with size x multiply y multiply z, and *[*[*[x y] z] Func] is an aray that same size containing Funcs.

	Or maybe each aray (including virtual arays) should have a type that is 0 or more other types.
	Example of 0 types: [] //may also be written as void
	Example of 1 type: [Func]
	Example of 2 types: [Func int]
	If x has type int, y has type [], and z has type Func, then *[*[x y] z] would have type [int Func].
	Type would always be a 1 dimensional aray that contains the concat of all 1-dimensional type arays of the data it iterates over recursively.

	That requires I define the idea of AudivolvType and allow arays of AudivolvType.
	Example: The type of an iteration over [Func int] is [AudivolvType], and the type of [AudivolvType] is [AudivolvType].

	Example AudivolvTypes: ob, flo, int, func, flofunc.

	That changes how multiple iterators can be defined for the same aray.
	Example: a real flo aray size *[*[x y] z] can be iterated linarly with type [flo] but also can be iterated as type [type_of_x type_of_z] and also can be iterated as type [type_of_x type_of_z flo]. The *[*[x y] z] aray can be iterated as flo at the same time as any of its childs.

	Unless its interpreted as more virtual, the node definition includes explicit arays and types, and what I wrote in the last few lines only applies to iterators.

	Maybe each aray's types should always include all recursive types, and allow ignoring any of those types.
	Example: *[*[x y] z] is a flo aray and its type is [type_of_x type_of_y type_of_z flo], and you can iterate over it using any subset of [type_of_x type_of_y type_of_z flo] but must keep the order of that aray.
	Each func call during iterating with types [type_of_x type_of_y type_of_z flo] must have a definition with that same aray with void replacing the things that will not be used. Example: [void type_of_y void flo] and the type that the Func uses would be [type_of_y flo].

	Ok use this design. Now bring back part of the example from above:

	b = *2+1.*2 with type [] //2
	c = *2+1.*2+1 with type [] //3
	d = *2+1.*2.*2 with type [] //4
	*bc = *[b c]  with type []
	*d*bc = *[d *bc] with type [flo]
	^d*bc = *d*bc.^ with type [flo]
	loopRoot = ^d*bc.*^ with type [flo flo]

	do[
		*d*bc.loop[flo=[*d*bc flo0]]
		loopRoot.loop[flo+=[*d*bc ^d*bc]]
		loopRoot.loop[do[ ...multiple commands... ]]
	]

	Should the node for that example be written this way?:
	node#nodeExample[
		void#b[*2+1.*2] //has recursive type []
		void#c[*2+1.*2+1] //has recursive type []
		void#d[*2+1.*2.*2] //has recursive type []
		void#*bc[*[b c]] //has recursive type []
		flo#*d*bc[*[d *bc]] //has recursive type [flo]
		flo#^d*bc[*d*bc.^] //has recursive type [flo flo]
		void#loopRoot[^d*bc.*^] //has recursive type [flo flo]
	]




	How to define heapQueues?
	[QUOTE FROM ABOVE]
		theHeapQueue = +[
			hqForward = *[hqSize=59 int]
			hqReverse = *[hqSize int]
			hqFlo = *[hqSize flo]
			hqOb = *[hqSize ob]
		]
	[END QUOTE FROM ABOVE]
	???

	How to define a Func that is used with loopRoot?
	node#theFunc[
		loopRoot.flo=[*d*bc flo0]
		loopRoot.flo+=[*d*bc ^d*bc]
	]
	???

	While iterating, can a func refer to 2 different flo in the same flo aray?
	Example node:
		node#eNode[
			flo#p[2]
			void#q[3]
			flo#r[5]
			flo#s[*[p r]]
			flo#t[*[q r]]
			void#theIterator[*[s t]]
		]
	Example func thats used with theIterator:
		+#eFunc[ //node is constant size aray. + is a type of node that executes each thing inside it in order.
			loopRoot.flo+=[s t] //This is easy to define
			loopRoot.flo+=[s.r t.r] //This definition may complicate the design. Look at it closely.
			//s.r and t.r are the same r aray but with different current indexs.
		]

	During iteration, should the type of theIterator be written as [s.p s.r s t.r t]? That does not say void q is included.
	Should it be written as void#theIterator[flo#s[flo#p flo#r] flo#t[void#q flo#r]]?
	Should it be written as void[flo[flo flo] flo[void flo]]?
	Should it be written in depth-first order with aray names only, and look up the other info if needed?:
		[theIterator s p r t q r]?
	Should it be written in depth-first order with aray names and types:
		[void#theIterator flo#s flo#p flo#r flo#t void#q flo#r]?

	Types during iteration can be calculated at runtime.
	I need a syntax to specify which path is taken to each aray when a func uses that aray, which is a different problem.

	The parameter types of a Func are a 1 dimensional aray, but the definition of a Func should use syntax like this:
		theIterator.flo+=[s.r t.r]

	Can the same syntax for defining nodes be used to define Funcs and their parts?:
		theIterator#flo+=[s.r t.r]
	Does this work?:
		flo+=#thePlusEq[theIterator.s.r theIterator.t.r]

	While iterating over theIterator, I need the ability to use arays in an order other than is defined as theIterator's type.

	Iterating needs to be able to run multiple commands in a do[ ...multiple commands here... ] (or should do be called +).
		do#aFunc[
			someCommand
			someOtherCommand
			theIterator#nameOfThisFuncPart[flo+=[s[r#nameOfFirstR] t#nameOfThisT[r]] //anything can be named
		]

	Because do is +, can +#plus0[+#plus1[a b] +#plus2[c b]] be viewed as a 1 dimensional aray ever?
	Can an aray size +[+#plus1[a b] +#plus2[c b]] be defined this way?
		flo#aFloAray[+#plus0[+#plus1[a b] +#plus2[c b]]]
	An int aray the ame size should be definable this way:
		int#anIntAray[aFloAray]
	For iterating over anIntAray, a func should be definable this way:
		+#funcForInt[
			someCommand
			someOtherCommand
			anIntAray[intSwap[plus0[plus1[b]] plus0[plus2[b]]]]
		]

	Is this syntax better?
		+#funcForInt[
			someCommand
			someOtherCommand
			anIntAray[intSwap[plus0.plus1.b plus0.plus2.b]]
		]

	Should plus1.b be an abbrev for plus0.plus1.b when plus1 is only used once in the current namespace? Both are paths to the b aray.

	void#theIterator[*#theMult[s t]] means a void aray size s*t, and theIterator#abc[theMult[t]] means to use the t aray while iterating over theIterator and to call that iteration abc.
	It could be abbreviated theIterator#abc[t].
	PROBLEM: Why isnt theIterator#abc[t] a variation of theIterator that is size t?
		How to define a variation of theIterator that is size t?
			Because theIterator is variable-size (not a node), variations of it are not allowed. Variations of constant-size things are allowed.

	The root type is variable-size, and so are many of the subtypes.
	There are constant-size subtypes of variable-size types, but no subtype of a constant-size type can be variable-size.

	That would get rid of the dot syntax. How would audivolv.flo be written?
	If its written as audivolv[flo], then is a size-3 flo aray named abc written as audivolv[flo]#abc[3]?
	That syntax does not make sense.
	Instead, define flo this way: audivolv#flo
		and define the flo aray this way: flo#abc[3]

	*[s t] is a size-2 aray so why isnt void#theIterator[*[s t]] a size-2 aray?
		Should it be written with a different syntax for variable/constant size?: void#theIterator[*(s t)]
			Extra syntax should be avoided if possible.

	Some operators have a math meaning when applied to ints. Examples: + * ^ *^ ^*

	+#aPlus[3 4]
	flo#aFloAray[aPlus]
	Because aPlus is size 2, is aFloAray size 2 or size 7?
	Should it be written this way?: size+#aPlus[3 4] and flo#aFloAray[size=[aPlus]]
	Because size=[aPlus] is a size-1 aray, why isnt flo#aFloAray[size=[aPlus]] a size 1 aray?

	If the dot syntax is not used, how to define 5 in terms of *2 *2+1?
	Previously it was: *2+1.*2.*2+1
	Now the syntax is: *2+1[*2[*2+1]]
		???

	Aray sizes can only be defined with a very small set of operators, by design. Those operators are: *2 *2+1 + * ^ *^ ^*

	Audivolv's design requires these operators be hard-coded and no more can be created, so why shouldnt they have their own syntax?

	*2+1(*2(*2+1))

	Should parenthesis() mean calculate int size, and square brackets[] mean aray?

	Should parenthesis also mean call a func?

	[QUOTE FROM ABOVE]
		node#eNode[
			flo#p[2]
			void#q[3]
			flo#r[5]
			flo#s[*[p r]]
			flo#t[*[q r]]
			void#theIterator[*[s t]]
		]
	[END QUOTE FROM ABOVE]

	Should every func have exactly 1 return type, which can be void?
	Example:
		flo#funcThatReturnsAFlo( do( +(p r) ...otherActions... *(s t) ) )
		???

	This syntax should be able to define a func that returns a single flo and a func that returns a flo aray size *(s t).

	Example func that returns a single flo:
		flo#returnsAFloAray( do( +(p r) ...otherActions... *(s t) ) )
		???

	Example func that returns a flo aray size *(s t):
		flo#returnsAFloAray[ do( +(p r) ...otherActions... *(s t) ) ]
		???

	Example func that (for no reason) iterates through an int aray size +(p r) and returns a single flo:
		flo#returnsAFloAray[ do( int[+(p r)] ...otherActions... *(s t) ) ]
		???

	Should constant size things be written with {}, aray sizes [], and funcs ()?
	nodeWithAFloAray{
		flo#theFloAray[*(+(5 6) 7)]
	}
	What is gained by using {} instead of [] here?

	How to define a func that returns a flo aray size 100 with the specific flos 50.3 51.3 ... 149.3?
		flo#oneHundredSpecificFlos[100]
		do(
			flo=(flo#floVal flo50p3)
			oneHundredSpecificFlos#theFlos(
				flo=( theFlos flo+=(floVal flo1) )
			)
		)

	Should it be written this way?:
		flo#oneHundredSpecificFlos[
			do(
				flo=(flo#floVal flo50p3)
				oneHundredSpecificFlos(
					flo=( oneHundredSpecificFlos flo+=(floVal flo1) )
				)
				100
			)
		]
	That is complex. Variable-size arays should not be defined in the same place as their contents.

	Parenthesis(...) contain a function definition, where the function has 1 return value or void.

	Square brackets[...] contain something that defines the size of a variable-size aray. They contain an aray of a certain size to equal that aray's size or they contain a func() that returns an int or a func() that returns an aray (use the size of that aray).

	Curly braces{...} are the contents of some constant-size aray. Example: +{3 4} is the literal idea of adding 3 to 4. +(3 4) is running the function and calculating 7. +[2] means a + that contains 2 things. +{3 4} is an example of a + with 2 things.

	The pound/number symbol # always names things and is optional. Example: +#thePlus{3 4} or +{3 4} are equal if that name is not needed.

	[QUOTE FROM ABOVE] //loopRoot should be called theIterator
		Example node:
			node#eNode[
				flo#p[2]
				void#q[3]
				flo#r[5]
				flo#s[*[p r]]
				flo#t[*[q r]]
				void#theIterator[*[s t]]
			]
		Example func thats used with theIterator:
			+#eFunc[ //node is constant size aray. + is a type of node that executes each thing inside it in order.
				loopRoot.flo+=[s t] //This is easy to define
				loopRoot.flo+=[s.r t.r] //This definition may complicate the design. Look at it closely.
				//s.r and t.r are the same r aray but with different current indexs.
			]
	[END QUOTE FROM ABOVE]

	node#eNode{
		flo#p[int2]
		void#q[int3]
		flo#r[int5]
		flo#s[*(p r)]
		flo#t[*(q r)]
		void#theIterator[*(s t)]
		do#eFunc(
			theIterator(flo+=(s t))
			theIterator(flo+=(s{r} t{r}))
		)
		do#otherFunc(
			theIterator(
				do(
					flo+=(s t)
					flo+=(s{r} t{r})
				)
			)
			otherAction
		)
	}

	Should there be an extra syntax for looping over an aray?
	Example aray:
		void#theIterator[*(s t)]
	Example loop syntax:
		theIterator#aSpecificIterator( //does this need a do( ... ) around those 2 actions?
			flo+=(s t)
			flo+=(s{r} t{r})
		)

	How to create *^ from a ^ which was createdrom a *? They should explicitly have that heirarchy available.
	[QUOTE FROM ABOVE]
		weightAray = *[weightSumAray.^ weightFlo]
		theLoop = weightAray.*^
	[END QUOTE FROM ABOVE]

	flo#s[*(p r)]
	flo#t[*(q r)]
	void#theIterator[*(s t)]
	//ob#largeNumberOfChilds[theIterator.*^] //I'm trying to remove the dot syntax, but it looks useful here. This is *(t ^(s t)) quantity of obs.
	ob#largeNumberOfChilds[*^(theIterator{s} theIterator{t})] //I'm trying to remove the dot syntax, but it looks useful here. This is *(t ^(s t)) quantity of obs.

	Maybe the hard-coded aray size operators (+ ^ *^ *2+1 etc) should not be written the same way funcs are defined.
	Maybe node should be a type of + and use [] instead of {}.

	eNode{
		...TODO REWRITE THIS STUFF...
		p[flo int2]
		q[void int3]
		r[flo int5]
		s[flo * p r]
		t[flo * q r]
		theIterator[void * s t]
		largeNumberOfChilds[eNode theIterator.*^] //which of these to use?
		largeNumberOfChilds[eNode *^ theIterator.s theIterator.t] //which of these to use?
		do#eFunc(
			???
			theIterator(flo+=(s t))
			theIterator(flo+=(s.r t.r))
		)
		do#otherFunc(
			???
			theIterator(
				do(
					flo+=(s t)
					flo+=(s.r t.r)
				)
			)
			otherAction
		)
		...TODO REWRITE THIS STUFF...
	}

	There are a few main things Audivolv needs syntax(s) for. If combining those syntaxs is complicating things, then make them separate.
	Things syntax is needed for:
		* arays in a node, their types, their sizes, and their dependencies on eachother.
		* flofunc (run on a flo aray).
		* func (run on a node, or maybe a specific aray in a node and what descends from it).

	If the same aray can not be used multiple times in calculating another arays size, then things like flo+=(s.r t.r) are not needed. Instead, the 2 paths to r would have different names, and there would be no need to give the whole path.

	eNode{ //TODO use a different syntax for defining nodes than for defining
		p[flo int2]
		q[void int3]
		r,r2[flo int5] //This aray has 2 names. There are not 2 arays. It does not change the definition of the node.
		s[flo * p r]
		t[flo * q r2]
		theIterator[void * s t]
		largeNumberOfChilds[eNode *^of* theIterator] //*^of* can only be used with a * parameter.
		eFunc[void largeNumberOfChilds]{ //a loop the same size as largeNumberOfChilds
			nameOfThisCodePart(flo+= s t) //Lisp-like syntax for calling funcs on values in arays, except it can have an explicit name.
		}
		fFunc[void theIterator]{ //a loop the same size as theIterator
			(flo+= r r2)
		}
		//Should this syntax be used instead?:
		eFunc(largeNumberOfChilds nameOfThisCodePart(flo+= s t))
		//Or written without the name nameOfThisCodePart:
		eFunc(largeNumberOfChilds (flo+= s t))
		//That is a good syntax. It can also have multiple commands:
		eFunc(largeNumberOfChilds (flo+= s t) (flo= t flo3) (flo=sine s t))
	}

	Should t[flo * q r2] be written as t<flo>[* q r2], or if it was void instead of flo, written as t[* q r2]?

	eNode{ //TODO use a different syntax for defining nodes than for defining
		p<flo>[int2]
		q[int3]
		r,r2<flo>[int5]
		s<flo>[* p r]
		t<flo>[* q r2]
		theIterator[* s t]
		largeNumberOfChilds<eNode>[*^of* theIterator]
		eFunc(largeNumberOfChilds nameOfThisCodePart(flo+= s t))
		fFunc(theIterator (flo+= r r2))
		gFunc(largeNumberOfChilds nameOfThisCodePart(flo+= s t))
		hFunc(largeNumberOfChilds (flo+= s t))
		iFunc(largeNumberOfChilds (flo+= s t) (flo= t flo3) (flo=sine s t))
	}

	Maybe every [] should have the type first, then operator and aray name(s), like this: t[flo * q r2].

	eNode{ //{...} means constant-size aray containing aray definitions and funcs, which depend on eachother.
		p<flo>[int2]
		q[int3]
		r,r2<flo>[int5]
		s<flo>[* p r]
		t<flo>[* q r2]
		theIterator[* s t]
		largeNumberOfChilds<eNode>[*^of* theIterator]
		eFunc(largeNumberOfChilds nameOfThisCodePart(flo+= s t))
		fFunc(theIterator (flo+= r r2))
		gFunc(largeNumberOfChilds nameOfThisCodePart(flo+= s t))
		hFunc(largeNumberOfChilds (flo+= s t))
		iFunc(largeNumberOfChilds (flo+= s t) (flo= t flo3) (flo=sine s t))
		//How to create jFunc which calls fFunc then gFunc which have different iteration sizes?
		jFunc(do fFunc gFunc)
		//How do I create an if-statement in a func?:
		kFunc(if someBoolean_howDoIDefineBoolean fFunc gFunc)
		//Define a boolean func
		aBooleanFunc(flo<= flo3point14 flo4point56)
		lFunc(theIterator (if (flo<= p r2) fFunc gFunc))
	}

	May need to give more detail or change these:
		Syntax for specifying return type of a func.
		Syntax for specifying type of an aray.

	Need to specify this for the first time:
		Syntax for using heapQueue with child of child and other arays.


	heapQueueSize[void 15]
	hqForward<int>[heapQueueInt heapQueueSize]
	hqReverse<int>[heapQueueTni heapQueueSize]
	hqFlo<flo>[heapQueueFlo heapQueueSize]

	Can view heapQueue as this:
	aViewOfTheHq<flo>[heapQueueViewFlo hqForward hqReverse hqFlo] //must be 3 specific operators: heapQueueInt, heapQueueTni, and heapQueueFlo.

	Optional aray:
	hqNode<ob>[heapQueueNode heapQueueSize]

	Can view heapQueue and optional aray as this:
	aViewOfTheHq<flo ob>[heapQueueViewFloNode aViewOfTheHq hqNode] //must be 2 specific operators: heapQueueViewFlo and heapQueueNode.


	This is an example node from an earlier design document. Try to rewrite it below this quote using this new syntax.
	[QUOTE FROM createExampleNode.13.1.xml]
		<araysOfExampleNode>
			int myInts[1] //size is defined as constant 1
			Func myFuncs[araysInConstantDepthRecursion.length] //size is defined as constant, number of Funcs in this Node.

			int hq[h]        //size is defined in some range. Index always stays at 0 (or 1?).
			int hqReverse[h] //size func: size=(hq hqReverse)
			flo hqFlo[h]   //size func: size=(hq hqFlo)
			Ob hqNode[h] //size func: size=(hq hqNode)

			Ob child[c]    //size is defined in some range
			flo childWeight[c] //size func: size=(childWeight child)
			////////ABOVE ARRAYS ARE REAL, BELOW ARE VIRTUAL////////

			//Get first hq node 1 time.
			Ob hqCurNode[] //func: pointer(hq hqCurNode)
			flo hqCurValue[]   //func: pointer(hq hqCurValue)

			//Get variable-size child array of that node. Iterate over each child.
			Ob childOfHqCurNode[]    //func: arayInChild(hqCurNode child childOfHqCurNode)
			flo childWeightOfHqCurNode[] //func: arayInChild(hqCurNode childWeight childWeightOfHqCurNode)

			//Find a child in hq. This is 1 thing to do in the existing iteration.
			Ob hqNodeForChildOfHqCurNode[] is virtual view of hqNode[]. //func: logSearchForNode(childOfHqCurNode hqNodeForChildOfHqCurNode) //TODO What if its not found? Should that be an error? Should it give index -1, index 0, null?
			flo hqFloForChildOfHqCurNode[] is virtual view of hqFlo[]. //func: index=(hqNodeForChildOfHqCurNode hqFloForChildOfHqCurNode)

			//TODO use bit array (maybe size 1) to store the boolean value of if hqCurValue is big enough to continue

			? rootIterAndCodeOfExampleNode = ...defined below...
		</araysOfExampleNode>

		<Func>
			sequence(
				viewAray(hqNode hqNodeForChildOfHqCurNode) //hqNode goes in multiple places so we can have 2 curIndex for it.
				viewAray(hqFlo hqFloForChildOfHqCurNode) //hqFlo goes in multiple places so we can have 2 curIndex for it.
				viewAray(hqNode hqCurNode)
				viewAray(hqFlo hqCurValue)
				pointer(hq hqCurNode) //set curIndex of hqCurNode to the highest in the hq
				pointer(hq hqCurValue) //set curIndex of hqCurNode to the highest in the hq
				arayInChild(hqCurNode child childOfHqCurNode)
				arayInChild(hqCurNode childWeight childWeightOfHqCurNode)
				flo-=(hqCurValue ???totalAmountChange???)
				hqFloChanged(???hq??? ???hqReverse??? hqCurValue) //should this be merged with flo-=(...) above?
				recurse(
					childOfHqCurNode
					sequence(
						logSearchForNode(childOfHqCurNode hqNodeForChildOfHqCurNode)
						index=(hqNodeForChildOfHqCurNode hqFloForChildOfHqCurNode)
						flo+=(hqFloForChildOfHqCurNode ???totalAmountChangeDividedByChildQuantity???)
						hqFloChanged(???hq??? ???hqReverse??? hqFloForChildOfHqCurNode) //should this be merged with flo+=(...) above?
					)
				)
			)
		</Func>
	[END QUOTE FROM createExampleNode.13.1.xml]


	exampleNode{
		...TODO FINISH TRANSLATING THIS FROM THE OLD EXAMPLE NODE TO THE NEW SYNTAX...
		myInts<int>[1] //size is defined as constant 1
		h[15] //heapQueue size
		hq<int>[heapQueueInt h]
		hqReverse<int>[heapQueueTni h]
		hqFlo<flo>[heapQueueFlo h]
		hqViewFlo[heapQueueViewFlo hq hqReverse hqFlo] //size h and current index has max flo in hqFlo aray. Recursive data is <flo>.
		hqNode<exampleNode>[heapQueueNode h] //Must be sorted by "myInts<int>[1]"
		hqViewFloNode[heapQueueViewFloNode hqViewFlo hqNode] //Recursive data is <flo exampleNode>.
		hqViewNode[heapQueueViewNode hqViewFlo hqNode] //Recursive data is <exampleNode>.

		childCount[range 1 300]
		child<exampleNode>[childCount]
		childWeight<flo>[childCount]

		//Get first hq node 1 time.
		hqCurNode<exampleNode>[] //func: pointer(hq hqCurNode)
		hqCurValue<flo>[]   //func: pointer(hq hqCurValue)

		//Get variable-size child array of that node. Iterate over each child.
		childOfHqCurNode(hqViewNode ???) //returns child<exampleNode> aray from current exampleNode in hqNode //func: arayInChild(hqCurNode child childOfHqCurNode)
		childWeightOfHqCurNode<flo>[] //func: arayInChild(hqCurNode childWeight childWeightOfHqCurNode)

		//Find a child in hq. This is 1 thing to do in the existing iteration.
		hqNodeForChildOfHqCurNode<exampleNode>[] is virtual view of hqNode[]. //func: logSearchForNode(childOfHqCurNode hqNodeForChildOfHqCurNode) //TODO What if its not found? Should that be an error? Should it give index -1, index 0, null?
		hqFloForChildOfHqCurNode<flo>[] is virtual view of hqFlo[]. //func: index=(hqNodeForChildOfHqCurNode hqFloForChildOfHqCurNode)

		flo+=(hqFloForChildOfHqCurNode ???totalAmountChangeDividedByChildQuantity???)

		...TODO FINISH TRANSLATING THIS FROM THE OLD EXAMPLE NODE TO THE NEW SYNTAX...
	}

	In eNode above{
		t<flo>[* q r2]
		theIterator[* s t]
		largeNumberOfChilds<eNode>[*^of* theIterator]
		eFunc(largeNumberOfChilds nameOfThisCodePart(flo+= s t))
		fFunc(theIterator (flo+= r r2))
		gFunc(largeNumberOfChilds nameOfThisCodePart(flo+= s t))
		hFunc(largeNumberOfChilds (flo+= s t))
		iFunc(largeNumberOfChilds (flo+= s t) (flo= t flo3) (flo=sine s t))
	}
	How should all those be stored in memory? Would Object arays for everything work?
	Example: (flo+= s t) would be an Object aray size 3, and iFunc size 4, and theIterator size 4 and containing something like: defFloAray, size*, s, and t. Or theIterator could be size 3, something like: [defAray flo [* s t]]. All of those are too complex.
	Or maybe those Object arays should be nodes that contain arays containing the things in that Example.

	Should (flo+= s t) be defined as a node like this?:
	flo+={
		myInts<int>[1] //all nodes have an int here
		firstFlo<flo>[1]
		secondFlo<flo>[1]
	}
	Or this?
	flo+={
		myInts<int>[1] //all nodes have an int here
		floParameters<flo>[2]
	}
	Or this?
	flo+={
		myInts<int>[1] //all nodes have an int here
		firstFlo<flo>[1]
		secondFlo<flo>[1]
		thisFloPlusEqFunc<func>[1] //contains this func: (javaCode "f0 += f1")
	}
	Or redefine the first thing a node must contain from int[1] to Func, and make Func be an Object with a public final int var (for the same reason the int[1] was there), like this:
	flo+={
		Func //does this: (javaCode "f0 += f1") //Should Func extend java.lang.Number?
		firstFlo<flo>[1]
		secondFlo<flo>[1]
	}
	Probably should keep the int[1] first in each node, or an Integer because in Java 1.5 Integer can be efficiently unautoboxed.

	Should Audivolv standardly allow the Java types Comparable and/or Comparator? Should they allow nodes (Object aray) as parameters to execute those nodes?

	Do I have any use for networks of Comparator that only compare Comparator?
	What if they also implement Comparable or Number?
	It could combine with existing Audivolv node design by putting an aray Comparable[] and/or Comparator[] in some nodes.





</planToCreateTheFirstVersionOfAudivolv>



</syntaxPlanning>